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1. Introduction 


This memo defines a portion of the Management Information Base (MIB) 
for use with network management protocols in the Internet community. 
In particular, it describes managed objects for modeling a Transport 
Profile (TP) based on Multiprotocol Label Switching (MPLS) [RFC3031]. 


This MIB module should be used for performing the OAM (Operations, 
Administration, and Maintenance) operations for MPLS Tunnel LSPs 
(Label Switched Paths), Pseudowires, and Sections. 


At the time of this writing, SNMP SET is no longer recommended as a 
way to configure MPLS networks as was described in [RFC3812]. 
However, since the MIB modules specified in this document are 
intended to work in parallel with the MIB modules for MPLS specified 
in [RFC3812], certain objects defined here are specified with a 
MAX-ACCESS of read-write or read-create so that specifications of the 
base tables in [RFC3812] and the new MIB modules in this document are 
consistent. Although the example described in Section 6 specifies 
means to configure OAM identifiers for MPLS-TP Tunnels, this should 
be seen as indicating how the MIB values would be returned in the 
Specified circumstances having been configured by alternative means. 


2. The Internet-Standard Management Framework 


For a detailed overview of the documents that describe the current 
Internet-Standard Management Framework, please refer to section 7 of 
RFC3410 [RFC3410]. 


Managed objects are accessed via a virtual information store, termed 
the Management Information Base or MIB. MIB objects are generally 
accessed through the Simple Network Management Protocol (SNMP). 
Objects in the MIB are defined using the mechanisms defined in the 
Structure of Management Information (SMI). This memo specifies a MIB 
module that is compliant to the SMIv2, which is described in STD 58, 
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 


[RFC2580]. 
3. Overview 
3.1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
RFC 2119 [RFC2119]. 
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3.2. Terminology 
This document uses terminology from the Multiprotocol Label Switching 
Architecture [RFC3031], the MPLS Traffic Engineering (TE) MIB 
[RFC3812], the MPLS Label Switching Router (LSR) MIB [RFC3813], the 
OAM Framework for MPLS-Based Transport Networks [RFC6371], "MPLS 
Transport Profile (MPLS-TP) Identifiers" [RFC6370], MPLS-TP 
Identifiers Following ITU-T Conventions [RFC6923], and OAM in MPLS 
Transport Networks [RFC5860]. 

3.3. Acronyms 
BFD: Bidirectional Forwarding Detection 
ICC: ITU Carrier Code 
IP: Internet Protocol 
LSP: Label Switched Path 
LSR: Label Switching Router 

ME: Maintenance Entity 

MEG: Maintenance Entity Group 

MEP: Maintenance Entity Group End Point 

MIB: Management Information Base 

MIP: Maintenance Entity Group Intermediate Point 


MP: Maintenance Point 


MPLS: Multiprotocol Label Switching 


MPLS-TP: MPLS Transport Profile 
PW: Pseudowire 
TE: Traffic Engineering 


TP: Transport Profile 
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4. Feature List 


The MPLS transport profile OAM identifiers MIB module is designed to 
satisfy the following requirements and constraints: 


- The MIB module supports configuration of OAM identifiers for MPLS 
point-to-point Tunnels, point-to-multipoint LSPs, co-routed 
bidirectional LSPs, associated bidirectional LSPs, and 
Pseudowires. 


5. Brief Description of MIB Objects 


The objects described in this section support the functionality 
described in [RFC5654] and [RFC6370]. The tables support both 
IP-compatible and ICC-based OAM identifiers configurations for MPLS 
Tunnels, LSPs, and Pseudowires. 


5.1. mplsOamIdMegTable 


The mplsOamIdMegTable is used to manage one or more Maintenance 
Entities (MEs) that belong to the same transport path. 


When a new entry is created with mplsOamIdMegOperatorType set to 
ipCompatible (1), then as per [RFC6370] (MEG_ID for an LSP is LSP_ID, 
and MEG_ID for a PW is PW_Path_ID), MEP_ID can be automatically 
formed. 


For an ICC-based transport path, the user is expected to configure 
the ICC identifier explicitly in this table for MPLS Tunnels, LSPs, 
and Pseudowires. 


5.2. mplsOamIdMeTable 


The mplsOamIdMeTable defines a relationship between two points 
(source and sink) of a transport path to which maintenance and 
monitoring operations apply. The two points that define an ME are 
called Maintenance Entity Group End Points (MEPs). 


In between MEPs, there are zero or more intermediate points, called 


Maintenance Entity Group Intermediate Points (MIPs). MEPs and MIPs 
are associated with the MEG and can be shared by more than one ME in 
a MEG. 
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6. MPLS OAM Identifier Configuration for MPLS LSP: Example 


In this section, we provide an example of the OAM identifier 
configuration for an MPLS co-routed bidirectional LSP. 


This example provides usage of MEG and ME tables for management and 
monitoring operations of an MPLS LSP. 


This example considers the OAM identifiers configuration ona 
head-end LSR to manage and monitor an MPLS LSP. Only relevant 
objects that are applicable for IP-based OAM identifiers of MPLS 
co-routed bidirectional LSPs are illustrated here. 


In the mplsOamIdMegTable: 


{ 
-— MEG index (Index to the table) 


mplsOamIdMegIndex = 1, 
mplsOamIdMegName = "MEGI", 
mplsOamIdMegOperatorType = ipCompatible (1), 
mplsOamIdMegServicePointerType = lsp (1), 
mplsOamIdMegMpLocation = perNode (1), 


-- Mandatory parameters needed to activate the row go here 


mplsOamIdMegRowStatus = createAndGo (4), 
mplsOamIdMegPathFlow 
= coRoutedBidirectionalPointToPoint (2) 


} 


This will create an entry in the mplsOamIdMegTable to manage and 
monitor the MPLS Tunnel. 
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The following ME table is used to associate the path information 
to a MEG. 


Aldrin, 


In the mplsOamIdMeTable: 


{ 
-- ME index (Index to the table) 
mplsOamIdMeIndex 


-- MP index (Index to the table) 
mplsOamIdMeMpIndex 
mplsOamIdMeName 
mplsOamIdMeMpIfIndex 

-- The source MEP ID is derived from 
mplsOamIdMeSourceMepIndex 

-- The sink MEP ID is derived from 
mplsOamIdMeSinkMepIndex 
mplsOamIdMeMpType 
mplsOamIdMeMepDirection 
RowPointer MUST point to the firs 

MPLS LSP 
mplsOamIdMeServicePointer 

-- Mandatory parameters needed to act 
mplsOamIdMeRowStatus 
} 


th 


et al. Standards Track 


= mep 


1, 


1, 

"MEI", 

0, 

the IP-compatible MPLS LSP 
0, 

e IP-compatible MPLS LSP 
0, 

(1), 

down (2), 

t accessible column of an 


mplsTunnelName.1.1.10.20, 


ivate the row go here 
createAndGo (4) 
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7. MPLS OAM Identifiers MIB Definitions 


MPLS-OAM-ID-STD-MIB DEFINITIONS ::= BEGIN 
IMPORTS 
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, 
Unsigned32 
FROM SNMPv2-SMI -- RFC 2578 
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 
FROM SNMPv2-CONF -- RFC 2580 
RowStatus, RowPointer, StorageType 
FROM SNMPv2-TC -- RFC 2579 
SnmpAdminString 
FROM SNMP-FRAMEWORK-MIB -- RFC 3411 
IndexIntegerNextFree 
FROM DIFFSERV-MIB -- RFC 3289 
mplsStdMIB 
FROM MPLS-TC-STD-MIB -- RFC 3811 
InterfaceIndexOrZero, ifGeneralInformationGroup, 
ifCounterDiscontinuityGroup 
FROM IF-MIB; -- RFC 2863 
mplsOamIdStdMIB MODULE-IDENTITY 
LAST-UPDATED 


"2016010700002" -- January 07, 2016 
ORGANIZATION 

"Multiprotocol Label Switching (MPLS) Working Group" 
CONTACT-INFO 

"Sam Aldrin 

Google, Inc. 

1600 Amphitheatre Parkway 

Mountain View, CA 94043 

USA 

Email: aldrin.ietf@gmail.com 


Thomas D. Nadeau 
Email: tnadeau@lucidvision.com 


Venkatesan Mahalingam 

Dell, Inc. 

5450 Great America Parkway 

Santa Clara, CA 95054 

USA 

Email: venkat.mahalingams@gmail.com 
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Kannan KV Sampath 

Redeem 

India 

Email: kannankvs@gmail.com 


Ping Pan 
Infinera 


Sami Boutros 

VMware, Inc. 

3401 Hillview Ave. 

Palo Alto, CA 94304 

USA 

Email: sboutros@vmware.com" 


DESCRIPTION 
"Copyright (c) 2016 IETF Trust and the persons identified 
as authors of the code. All rights reserved. 


Redistribution and use in source and binary forms, with or 
without modification, is permitted pursuant to, and subject 
to the license terms contained in, the Simplified BSD 
License set forth in Section 4.c of the IETF Trust’s 

Legal Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info). 


This MIB module contains generic object definitions for 
MPLS OAM identifiers." 


-- Revision history 

REVISION 
"2016010700002" -- January 07, 2016 

DESCRIPTION 
"MPLS OAM Identifiers MIB objects for Tunnels, LSPs, 
Pseudowires, and Sections." 


::— ( mplsStdMIB 21 } 


-- Top-level components of this MIB module 


-- notifications 
mplsOamIdNotifications 
OBJECT IDENTIFIER ::= { mplsOamIdStdMIB O0 } 
-— tables, scalars 
mplsOamIdObjects OBJECT IDENTIFIER ::= { mplsOamIdStdMIB 1 } 
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-— conformance 
mplsOamIdConformance 
OBJECT IDENTIFIER ::= { mplsOamIdStdMIB 2 } 


-- Start of MPLS Transport Profile MEG table 


mplsOamIdMegIndexNext OBJECT-TYPE 


SYNTAX IndexIntegerNextFree (0..4294967295) 
MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 


"This object contains an unused value for 
mplsOamIdMegIndex, or a zero to indicate 
that none exist. Negative values are not allowed, 
as they do not correspond to valid values of 
mplsOamIdMegIndex." 

::= { mplsOamIdObjects 1 } 


mplsOamIdMegTable OBJECT-TYPE 


SYNTAX SEQUENCE OF MplsOamIdMegEntry 
MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 


"This table contains information about the Maintenance 
Entity Groups (MEGs). 


A MEG, as mentioned in the MPLS-TP OAM framework, defines 
a set of one or more Maintenance Entities (MEs). 
MEs define a relationship between any two points of a 
transport path in an OAM domain to which maintenance and 
monitoring operations apply." 

::= { mplsOamIdObjects 2 } 


mplsOamIdMegEntry OBJECT-TYPE 


SYNTAX MplsOamIdMegEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 


"An entry in this table represents an MPLS-TP MEG. 
An entry can be created by a network administrator 
or by an SNMP agent as instructed by an MPLS-TP OAM 
framework. 


When a new entry is created with 
mplsOamIdMegOperatorType set to ipCompatible (1), 

then as per RFC 6370 (MEG ID for an LSP is LSP ID, and 
MEG ID for a PW is PW Path ID), MEP ID can be 
automatically formed. 
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For a co-routed bidirectional LSP, MEG_ID is 
Al-(Global ID::Node ID::Tunnel Numj::2Z29-(Global, ID:: 
Node ID::Tunnel Num]::LSP Num. 


For an associated bidirectional LSP, MEG ID is 
Al-(Global ID::Node ID::Tunnel Num::LSP Num]):: 
Z9-(Global ID::Node ID::Tunnel Num::LSP Num]. 


For an LSP, MEP ID is formed using 
Global ID::Node ID::Tunnel Num::LSP Num. 


For a PW, MEG ID is formed using AGI:: 
Al-(Global ID::Node ID::AC ID):: 
Z9-(Global ID::Node ID::AC ID). 


For a PW, MEP ID is formed using 
AGI::Global ID::Node ID::AC ID. 


MEP ID is retrieved from the mplsOamIdMegServicePointer 
object based on the mplsOamIdMegServicePointerType value. 
The ICC MEG ID for an LSP and a PW is formed using the 
objects mplsOamlIdMegIdIcc and mplsOamIdMegIdUmc. 


MEP ID can be formed using MEG ID::MEP Index." 
REFERENCE 
"1. RFC 5860: Requirements for Operations, Administration, 
and Maintenance (OAM) in MPLS Transport Networks, 
May 2010. 
2. RFC 6371: Operations, Administration, and Maintenance 
Framework for MPLS-Based Transport Networks, 
September 2011, Section 3. 
3. RFC 6370: MPLS Transport Profile (MPLS-TP) Identifiers, 
September 2011. 
4. RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers 
Following ITU-T Conventions, May 2013." 
INDEX ( mplsOamIdMegIndex } 
::= ( mplsOamIdMegTable 1 } 
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MplsOamIdMegEntry ::= SEQUENCE { 
mplsOamIdMegIndex Unsigned32, 
mplsOamIdMegName SnmpAdminString, 
mplsOamIdMegOperatorType INTEGER, 
mplsOamIdMegIdCc SnmpAdminString, 
mplsOamIdMegIdIcc SnmpAdminString, 
mplsOamIdMegIdUmc SnmpAdminString, 
mplsOamIdMegServicePointerType INTEGER, 
mplsOamIdMegMpLocation INTEGER, 
mplsOamIdMegPathFlow INTEGER, 
mplsOamIdMegOperStatus INTEGER, 
mplsOamIdMegSubOperStatus BITS, 
mplsOamIdMegRowStatus RowStatus, 
mplsOamIdMegStorageType StorageType 
} 
mplsOamIdMegIndex OBJECT-TYPE 
SYNTAX Unsigned32 (1..4294967295) 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"Index for the conceptual row identifying a MEG within 
this MEG table. Managers should obtain new values for row 
creation in this table by reading mplsOamIdMegIndexNext." 
::— { mplsOamIdMegEntry 1 } 
mplsOamIdMegName OBJECT-TYPE 
SYNTAX SnmpAdminString (SIZE(0..48) ) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"Each MEG has a unique name amongst all those used or 
available to a service provider or operator. It 
facilitates easy identification of administrative 
responsibility for each MEG." 
::= ( mplsOamIdMegEntry 2 } 
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mplsOamIdMegOperatorType OBJECT-TYPE 
SYNTAX INTEGER { 
ipCompatible (1), 
iccBased (2) 


} 


MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


January 2016 


"Indicates the operator type for the MEG. Conceptual rows 
having 'iccBased' as the operator type MUST have valid 


values for the objects mplsOamIdMegIdIcc and 


mplsOamIdMegIdUmc when the row status is active." 


REFERENCE 
"1. RFC 6370: MPLS Transport Profile (MPLS-TP) 
September 2011. 
2. RFC 6923: MPLS Transport Profile (MPLS-TP) 


Identifiers, 


Identifiers 


Following ITU-T Conventions, May 2013, Section 3.1." 


DEFVAL ( ipCompatible } 
::= ( mplsOamIdMegEntry 3 } 


mplsOamIdMegIdCc OBJECT-TYPE 


SYNTAX SnmpAdminString (SIZE(0..2)) 
MAX-ACCESS read-create 

STATUS current 

DESCRIPTION 


"Global uniqueness is assured by concatenating the ICC 
with a Country Code (CC). The Country Code (alpha-2) 
is a string of two alphabetic characters represented 


with uppercase letters (i.e., A-Z). 


This object MUST contain a non-null value if 
the MplsOamIdMegOperatorType value is iccBased 
otherwise, a null value with octet size 0 
should be assigned." 

REFERENCE 


(2); 


"RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers 
Following ITU-T Conventions, May 2013, Section 3." 


DEFVAL {""} 
::= ( mplsOamIdMegEntry 4 } 
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mplsOamIdMegIdIcc OBJECT-TYPE 


SYNTAX SnmpAdminString (SIZE(0..6)) 
MAX-ACCESS read-create 

STATUS current 

DESCRIPTION 


"Unique code assigned to a network operator or service 
provider; maintained by the ITU-T. This is the 
ITU Carrier Code used to form the MEGID. 


This object MUST contain a non-null value if 
the MplsOamIdMegOperatorType value is iccBased (2); 
otherwise, a null value with octet size 0 
should be assigned." 
REFERENCE 
"RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers 
Following ITU-T Conventions, May 2013, Section 3.1." 
DEFVAL {""} 
::= { mplsOamIdMegEntry 5 } 


mplsOamIdMegIdUmc OBJECT-TYPE 


SYNTAX SnmpAdminString (SIZE(0..7)) 
MAX-ACCESS read-create 

STATUS current 

DESCRIPTION 


"Unique code assigned by a network operator or service 
provider. This code is appended to mplsOamIdMegIdIcc to 
form the MEGID. 

This object MUST contain a non-null value if 

the MplsOamIdMegOperatorType value is iccBased (2); 
otherwise, a null value with octet size 0 
should be assigned." 

REFERENCE 

"RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers 

Following ITU-T Conventions, May 2013, Section 7.1." 
DEFVAL {""} 
::= ( mplsOamIdMegEntry 6 } 
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mplsOamIdMegServicePointerType OBJECT-TYPE 


SYNTAX INTEGER { 
tunnel (1), 
lsp (2), 


pseudowire (3), 
section (4) 


} 


MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


"Indicates the service type for the MEG. 

If the service type indicates tunnel (1), the service 
pointer in the mplsOamIdMeTable points to an entry in 
the point-to-point mplsTunnelTable (RFC 3812). 


If the service type indicates lsp (2), the service pointer 
in the mplsOamIdMeTable points to an entry in 
the co-routed or associated bidirectional mplsTunnelTable. 


If the value is the pseudowire (3) service type, the 
service pointer in the mplsOamIdMeTable points to an entry 
in the pwTable (RFC 5601). 


If the value is the section (4) service type, the service 
pointer in the mplsOamIdMeTable points to an entry in 
the mplsTunnelTable (RFC 3812)." 
REFERENCE 
"1. RFC 3812: Multiprotocol Label Switching (MPLS) 
Traffic Engineering (TE) Management Information 
Base (MIB), June 2004. 
2. RFC 5601: Pseudowire (PW) Management Information 
Base (MIB), July 2009." 
DEFVAL ( lsp } 
::= ( mplsOamIdMegEntry 7 ] 
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mplsOamIdMegMpLocation OBJECT-TYPE 


Aldrin, 


SYNTAX INTEGER { 
perNode (1), 
perInterface (2) 


} 


MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


"Indicates the MP location type for this MEG. 


If the value is perNode, then the MEG in the LSR supports 
only perNode MEPs/MIPs, i.e., only one MEP/MIP in an LSR. 


If the value is perInterface, then the MEG in the LSR 
supports perInterface MEPS/MIPs, i.e., two MEPS/MIPs in 
an LSR." 
REFERENCE 
"RFC 6371: Operations, Administration, and Maintenance 
Framework for MPLS-Based Transport Networks, 
September 2011." 
DEFVAL { perNode } 
:- ( mplsOamIdMegEntry 8 } 


mplsOamIdMegPathFlow OBJECT-TYPE 
SYNTAX INTEGER { 
unidirectionalPointToPoint (1), 
coRoutedBidirectionalPointToPoint (2), 
associatedBidirectionalPointToPoint (3), 
unidirectionalPointToMultiPoint (4) 


} 


MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


"Indicates the transport path flow for this MEG. 

In the case of a unidirectional point-to-point transport 
path, a single unidirectional ME is defined to monitor it. 
In the case of associated bidirectional point-to-point 
transport paths, two independent unidirectional MEs are 
defined to independently monitor each direction. 

In the case of co-routed bidirectional point-to-point 
transport paths, a single bidirectional ME is defined to 
monitor both directions congruently. 

In the case of unidirectional point-to-multipoint transport 
paths, a single unidirectional ME for each leaf is defined 
to monitor the transport path from the root to that leaf." 
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REFERENCE 
"RFC 6371: Operations, Administration, and Maintenance 
Framework for MPLS-Based Transport Networks, 
September 2011." 

DEFVAL ( coRoutedBidirectionalPointToPoint } 

::— { mplsOamIdMegEntry 9 } 


mplsOamIdMegOperStatus OBJECT-TYPE 
SYNTAX INTEGER { 
up (1), 
down (2) 
} 
MAX-ACCESS read-only 


STATUS current 

DESCRIPTION 
"This object specifies the operational status of the 
Maintenance Entity Group (MEG). This object is used to 


send the notification to the SNMP manager about the MEG. 


The value up (1) indicates that the MEG and its monitored 
path are operationally up. The value down (2) indicates 
that the MEG is operationally down. 


When the value of mplsOamIdMegOperStatus is up (1), 

all the bits of mplsOamIdMegSubOperStatus must be cleared. 

When the value of mplsOamIdMegOperStatus is down (2), 

at least one bit of mplsOamIdMegSubOperStatus must be set." 
::= { mplsOamIdMegEntry 10 } 


mplsOamIdMegSubOperStatus OBJECT-TYPE 
SYNTAX BITS { 
megDown (0), 
meDown (1), 
oamAppDown (2), 
pathDown (3) 
} 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"This object specifies the reason why the MEG operational 
status, as indicated by the object mplsOamIdMegOperStatus, 
is down. This object is used to send the notification to 
the SNMP manager about the MEG. 


The bit 0 (megDown) indicates that the MEG is down. 

The bit 1 (meDown) indicates that the ME table is down. 
The bit 2 (oamAppDown) indicates that the OAM application 
(LSP or PW) monitored by this MEG is down. Currently, BFD 
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is the only supported OAM application. 
The bit 3 (pathDown) indicates that the underlying 
LSP or PW is down." 

::= { mplsOamIdMegEntry 11 } 


mplsOamIdMegRowStatus OBJECT-TYPE 


SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


"This variable is used to create, modify, and/or delete 
a row in this table. When a row in this table is in the 
active(1) state, no objects in that row can be modified 
by the agent except mplsOamIdMegRowStatus." 

:= { mplsOamIdMegEntry 12 } 


mplsOamIdMegStorageType OBJECT-TYPE 


SYNTAX StorageType 

MAX-ACCESS read-create 

STATUS current 

DESCRIPTION 
"This variable indicates the storage type for this 
object. 


Conceptual rows having the value 'permanent' 
need not allow write access to any columnar 
objects in the row." 

DEFVAL { volatile } 

::= ( mplsOamIdMegEntry 13 } 


-- End of MPLS Transport Profile MEG table 


-- Start of MPLS Transport Profile ME table 


mplsOamIdMeIndexNext OBJECT-TYPE 


SYNTAX IndexIntegerNextFree (0..4294967295) 
MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 


"This object contains an unused value for 
mplsOamIdMeIndex, or a zero to indicate 
that none exist. Negative values are not allowed, 
as they do not correspond to valid values of 
mplsOamIdMeIndex." 

:= ( mplsOamIdObjects 3 } 


Aldrin, et al. Standards Track [Page 18] 


RFC 7697 MPLS-TP OAM ID MIB January 2016 


mplsOamIdMeMpIndexNext OBJECT-TYPE 


SYNTAX IndexIntegerNextFree (0..4294967295) 
MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 


"This object contains an unused value for 
mplsOamIdMeMpIndex, or a zero to indicate 
that none exist. Negative values are not allowed, 
as they do not correspond to valid values of 
mplsOamIdMeMpIndex." 

::= ( mplsOamIdObjects 4 } 


mplsOamIdMeTable OBJECT-TYPE 


SYNTAX SEQUENCE OF MplsOamIdMeEntry 
MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 


"This table contains MPLS-TP ME information. 


The ME is some portion of a transport path that requires 
management bounded by two points (called MEPs), and the 
relationship between those points to which maintenance 
and monitoring operations apply. 


This table is generic enough to handle MEP and MIP 
information within a MEG." 


::= { mplsOamIdObjects 5 } 


mplsOamIdMeEntry OBJECT-TYPE 


SYNTAX MplsOamIdMeEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 


"An entry in this table represents an MPLS-TP ME. This 
entry represents the ME if the source and sink MEPs are 
defined. 


An ME is a point-to-point entity. One ME has two such 
MEPS. A MEG is a group of one or more MES. One MEG can 
have two or more MEPs. 


For a point-to-point LSP, one MEG has one ME, and this ME 
is associated with two MEPs (source and sink MEPs) within 
a MEG. Each mplsOamIdMeIndex value denotes the ME within 
a MEG. 
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In the case of unidirectional point-to-point transport 
paths, a single unidirectional ME is defined to monitor 
it, and mplsOamIdMeServicePointer points to a 


unidirectional point-to-point path. 


In the case of associated bidirectional point-to-point 
transport paths, two independent unidirectional 

MES are defined to independently monitor each direction, 
and each mplsOamIdMeServicePointer MIB object points toa 
unique unidirectional transport path. 

This has implications for transactions that terminate at 
or query a MIP, as a return path from a MIP to a source 
MEP does not necessarily exist within the MEG. 


In the case of co-routed bidirectional point-to-point 
transport paths, a single bidirectional ME is defined to 
monitor both directions congruently, and the 
mplsOamIdMeServicePointer MIB object points to a co-routed 
bidirectional point-to-point transport path. 


In the case of unidirectional point-to-multipoint transport 
paths, a single unidirectional ME for each leaf is defined 
to monitor the transport path from the root to that leaf, 
and each leaf has different transport path information in 


the mplsOamIdMeServicePointer MIB object. 


Note that the 


MplsOamIdMeEntry should be created manually once the MEG 


is configured for OAM operations." 


INDEX ( mplsOamIdMegIndex, 
mplsOamIdMeIndex, 
mplsOamIdMeMpIndex 

} 
::= { mplsOamIdMeTable 1 } 


MplsOamIdMeEntry ::= SEQUENCE { 


mplsOamIdMeIndex 
mplsOamIdMeMpIndex 
mplsOamIdMeName 
mplsOamIdMeMpIfIndex 
mplsOamIdMeSourceMepIndex 
mplsOamIdMeSinkMepIndex 
mplsOamIdMeMpType 
mplsOamIdMeMepDirection 
mplsOamIdMeServicePointer 
mplsOamIdMeRowStatus 
mplsOamIdMeStorageType 


Standards Track 


Unsigned32, 
Unsigned32, 
SnmpAdminString, 
InterfaceIndexOrZero, 
Unsigned32, 
Unsigned32, 
INTEGER, 
INTEGER, 
RowPointer, 
RowStatus, 
StorageType 
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mplsOamIdMeIndex OBJECT-TYPE 


SYNTAX Unsigned32 (1..4294967295) 
MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 


"Uniquely identifies an ME index within a MEG. Managers 
should obtain new values for row creation in this table by 
reading mplsOamIdMeIndexNext." 

::= ( mplsOamIdMeEntry 1 } 


mplsOamIdMeMpIndex OBJECT-TYPE 


SYNTAX Unsigned32 (1..4294967295) 
MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 


"Indicates the Maintenance Point (MP) index that is used to 
create multiple MEPs in a node of a single ME. The value 
of this object can be the MEP index or the MIP index. 
Managers should obtain new values for row creation in this 
table by reading mplsOamIdMeMpIndexNext." 

::= ( mplsOamIdMeEntry 2 } 


mplsOamIdMeName OBJECT-TYPE 


SYNTAX SnmpAdminString (SIZE(1..48) ) 
MAX-ACCESS read-create 

STATUS current 

DESCRIPTION 


"This object denotes the ME name. Each ME has a unique 
name within a MEG." 
:= { mplsOamIdMeEntry 3 } 


mplsOamIdMeMpIfIndex OBJECT-TYPE 


SYNTAX InterfaceIndexOrZero 
MAX-ACCESS read-create 

STATUS current 

DESCRIPTION 


"Indicates the MP interface. 

If the mplsOamIdMegMpLocation object value 

is perNode (1), the MP interface index should point 

to the incoming interface or outgoing interface, or 

be zero (to indicate that the MP OAM packets are initiated 
from the forwarding engine). 


If the mplsOamIdMegMpLocation object value is 
perInterface (2), the MP interface index should point to 
the incoming interface or outgoing interface." 
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REFERENCE 
"1. RFC 6371: Operations, Administration, and Maintenance 


Framework for MPLS-Based Transport Networks, 
September 2011. 
2. RFC 2863: The Interfaces Group MIB, June 2000." 
DEFVAL { 0 } 
:= { mplsOamIdMeEntry 4 } 


mplsOamIdMeSourceMepIndex OBJECT-TYPE 


SYNTAX Unsigned32 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


"Indicates the source MEP index of the ME. This object 
should be configured if the mplsOamIdMegOperatorType object 
in the mplsOamIdMegEntry is configured as iccBased (2). 
If the MEG is configured for an IP-based operator, 
the value of this object should be set to zero, and the 
MEP ID will be automatically derived from the service 
identifiers (MPLS-TP LSP/PW Identifier) ." 

DEFVAL { 0 } 
:- { mplsOamIdMeEntry 5 } 


mplsOamIdMeSinkMepIndex OBJECT-TYPE 


Aldrin, 


SYNTAX Unsigned32 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


"Indicates the sink MEP index of the ME. This object 
should be configured if the mplsOamIdMegOperatorType object 
in the mplsOamIdMegEntry is configured as iccBased (2). 
If the MEG is configured for an IP-based operator, 
the value of this object should be set to zero, and the 
MEP ID will be automatically derived from the service 
identifiers (MPLS-TP LSP/PW Identifier) ." 

DEFVAL { 0 } 
:= { mplsOamIdMeEntry 6 } 
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mplsOamIdMeMpType OBJECT-TYPE 


SYNTAX INTEGER { 
mep (1), 
mip (2) 
} 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


"Indicates the MP type within the MEG. 


The object should have the value mep (1) only in the 
ingress or egress nodes of the transport path. 


The object can have the value mip (2) in the 
intermediate nodes and possibly in the egress nodes 
of the transport path." 

DEFVAL { mep } 

::= { mplsOamIdMeEntry 7 } 


mplsOamIdMeMepDirection OBJECT-TYPE 
SYNTAX INTEGER { 
up (1), 
down (2), 
notApplicable (3) 
} 


MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


"Indicates the direction of the MEP. This object 
should be configured if mplsOamIdMeMpType is configured 
as mep (1); otherwise, notApplicable (3) is set." 
DEFVAL { down } 
::= { mplsOamIdMeEntry 8 } 


mplsOamIdMeServicePointer OBJECT-TYPE 


SYNTAX RowPointer 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


"This variable represents a pointer to the MPLS-TP 
transport path. This value MUST point at an entry in the 
mplsTunnelEntry if mplsOamIdMegServicePointerType 

is configured as tunnel (1), lsp (2), or section (4), 

or at an entry in the pwEntry if 
mplsOamIdMegServicePointerType is configured 

as pseudowire (3). 
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Note: This service pointer object is placed in the ME table 
instead of the MEG table, since it will be useful in the 
point-to-multipoint case, where each ME will point to 
different branches of a point-to-multipoint tree." 

::= ( mplsOamIdMeEntry 9 } 


mplsOamIdMeRowStatus OBJECT-TYPE 


SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


"This variable is used to create, modify, and/or delete 
a row in this table. When a row in this table is in the 
active(1) state, no objects in that row can be modified 
by the agent except mplsOamIdMeRowStatus." 

::— { mplsOamIdMeEntry 10 } 


mplsOamIdMeStorageType OBJECT-TYPE 


SYNTAX StorageType 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


"This variable indicates the storage type for this object. 
Conceptual rows having the value 'permanent' 
need not allow write access to any columnar 
objects in the row." 
DEFVAL { volatile } 
::— { mplsOamIdMeEntry 11 } 


-- End of MPLS Transport Profile ME table 


-- End of MPLS-TP OAM tables 
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-- Notification definitions of MPLS-TP identifiers 


mplsOamIdDefectCondition NOTIFICATION-TYPE 


OBJECTS { 
mplsOamIdMegName, 
mplsOamIdMeName, 
mplsOamIdMegOperStatus, 
mplsOamIdMegSubOperStatus 

} 
STATUS current 
DESCRIPTION 


"This notification is sent whenever the operational 
status of the MEG is changed." 
::= { mplsOamIdNotifications 1 } 


-— End of notifications 


-- Module compliance 


mplsOamIdCompliances 
OBJECT IDENTIFIER ::= { mplsOamIdConformance 1 } 


mplsOamIdGroups 
OBJECT IDENTIFIER 


( mplsOamIdConformance 2 } 


-- Compliance requirement for fully compliant implementations 


mplsOamIdModuleFullCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION "Compliance statement for agents that provide full 
support for the MPLS-TP-OAM-STD-MIB. Such devices 
can then be monitored and also be configured 
using this MIB module." 


MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863 
MANDATORY-GROUPS { 
ifGeneralInformationGroup, 
ifCounterDiscontinuityGroup 


} 


MODULE -- this module 

MANDATORY-GROUPS { 
mplsOamIdMegGroup, 
mplsOamIdMeGroup 
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GROUP mplsOamIdNotificationObjectsGroup 

DESCRIPTION "This group is only mandatory for those 
implementations that can efficiently implement 
the notifications contained in this group." 


GROUP mplsOamIdNotificationGroup 

DESCRIPTION "This group is only mandatory for those 
implementations that can efficiently implement 
the notifications contained in this group." 


::= ( mplsOamIdCompliances 1 } 
-- Compliance requirement for read-only implementations 


mplsOamIdModuleReadOnlyCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 
"Compliance statement for agents that only provide 
read-only support for the MPLS-TP-OAM-STD-MIB module." 


MODULE -- this module 


MANDATORY-GROUPS { 
mplsOamIdMegGroup, 
mplsOamIdMeGroup 


GROUP mplsOamIdNotificationObjectsGroup 

DESCRIPTION "This group is only mandatory for those 
implementations that can efficiently implement 
the notifications contained in this group." 


GROUP mplsOamIdNotificationGroup 

DESCRIPTION "This group is only mandatory for those 
implementations that can efficiently implement 
the notifications contained in this group." 
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-- mplsOamIdMegTable 


OBJECT mplsOamIdMegName 
MIN-ACCESS  read-only 
DESCRIPTION 

"Write access is not required. 


OBJECT mplsOamIdMegOperatorType 
MIN-ACCESS read-only 
DESCRIPTION 


"Write access is not required. 


OBJECT mplsOamIdMegIdCc 
MIN-ACCESS  read-only 
DESCRIPTION 


"Write access is not required. 


OBJECT mplsOamIdMegIdIcc 
MIN-ACCESS  read-only 
DESCRIPTION 


"Write access is not required. 


OBJECT mplsOamIdMegIdUmc 
MIN-ACCESS  read-only 
DESCRIPTION 


"Write access is not required. 


OBJECT mplsOamIdMegServicePointerType 


MIN-ACCESS  read-only 
DESCRIPTION 
"Write access is not required. 


OBJECT mplsOamIdMegMpLocation 
MIN-ACCESS  read-only 
DESCRIPTION 


"Write access is not required. 


OBJECT mplsOamIdMegPathFlow 
MIN-ACCESS  read-only 
DESCRIPTION 


"Write access is not required. 


OBJECT mplsOamIdMegRowStatus 
SYNTAX RowStatus { active(1) } 
MIN-ACCESS  read-only 

DESCRIPTION 


"Write access is not required. 
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OBJECT mplsOamIdMegStorageType 
MIN-ACCESS read-only 
DESCRIPTION 


"Write access is not required. 
-- mplsOamIdMeTable 


OBJECT mplsOamIdMeName 
MIN-ACCESS  read-only 
DESCRIPTION 

"Write access is not required. 


OBJECT mplsOamIdMeMpIfIndex 
MIN-ACCESS  read-only 
DESCRIPTION 


"Write access is not required. 


OBJECT mplsOamIdMeSourceMepIndex 


MIN-ACCESS  read-only 
DESCRIPTION 
"Write access is not required. 


OBJECT mplsOamIdMeSinkMepIndex 
MIN-ACCESS  read-only 
DESCRIPTION 


"Write access is not required. 


OBJECT mplsOamIdMeMpType 
MIN-ACCESS read-only 
DESCRIPTION 


"Write access is not required. 


OBJECT mplsOamIdMeMepDirection 
MIN-ACCESS  read-only 
DESCRIPTION 


"Write access is not required. 


OBJECT mplsOamIdMeServicePointer 


MIN-ACCESS  read-only 
DESCRIPTION 
"Write access is not required. 


OBJECT mplsOamIdMeRowStatus 
SYNTAX RowStatus { active(1) } 
MIN-ACCESS  read-only 

DESCRIPTION 


"Write access is not required. 
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OBJECT mplsOamIdMeStorageType 
MIN-ACCESS read-only 
DESCRIPTION 


"Write access is not required." 
::= { mplsOamIdCompliances 2 } 
-- Units of conformance 


mplsOamIdMegGroup OBJECT-GROUP 
OBJECTS { 

mplsOamIdMegIndexNext, 
mplsOamIdMegName, 
mplsOamIdMegOperatorType, 
mplsOamIdMegIdCc, 
mplsOamIdMegIdIcc, 
mplsOamIdMegIdUmc, 
mplsOamIdMegServicePointerType, 
mplsOamIdMegMpLocation, 
mplsOamIdMegOperStatus, 
mplsOamIdMegSubOperStatus, 
mplsOamIdMegPathFlow, 
mplsOamIdMegRowStatus, 
mplsOamIdMegStorageType 


STATUS current 
DESCRIPTION 


"Collection of objects needed for MPLS MEG 


:= { mplsOamIdGroups 1 } 
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mIdMeGroup  OBJECT-GROUP 
ECTS { 
mplsOamIdMeIndexNext, 
mplsOamIdMeMpIndexNext, 
mplsOamIdMeName, 
mplsOamIdMeMpIfIndex, 
mplsOamIdMeSourceMepIndex, 
mplsOamIdMeSinkMepIndex, 
mplsOamIdMeMpType, 
mplsOamIdMeMepDirection, 
mplsOamIdMeServicePointer, 
mplsOamIdMeRowStatus, 
mplsOamIdMeStorageType 


STATUS current 


DES 


mplsOamIdNotificationObjectsGroup  OBJECT-GROUP 


CRIPTION 


January 2016 


"Collection of objects needed for MPLS ME information." 


( mplsOamIdGroups 2 ] 


OBJECTS { 


} 
STA 
DES 


mplsOamIdNotificationGroup NOTIFICATION-GROUP 


NOT 


) 
STA 
DES 


END 
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mplsOamIdMegOperStatus, 
mplsOamIdMegSubOperStatus 


TUS current 
CRIPTION 


"Collection of objects needed to implement notifications." 


{ mplsOamIdGroups 3 } 
IFICATIONS { 
mplsOamIdDefectCondition 


TUS current 
CRIPTION 


"Set of notifications implemented in this module." 


( mplsOamIdGroups 4 } 
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8. 


Security Considerations 


This MIB relates to a system that will provide network connectivity 
and packet forwarding services. As such, improper manipulation of 
the objects represented by this MIB may result in denial of service 
to a large number of end-users. 


There are a number of management objects defined in this MIB module 
with a MAX-ACCESS clause of read-write and/or read-create. Such 
objects may be considered sensitive or vulnerable in some network 
environments. The support for SET operations in a non-secure 
environment without proper protection opens devices to attack. 


Some of the readable objects in this MIB module (i.e., objects with a 
MAX-ACCESS other than not-accessible) may be considered sensitive or 
vulnerable in some network environments. It is thus important to 
control even GET and/or NOTIFY access to these objects and possibly 
to even encrypt the values of these objects when sending them over 
the network via SNMP. These are the tables and objects and their 
sensitivity/vulnerability: 


- The mplsOamIdMegTable and the mplsOamIdMeTable collectively show 
the MPLS OAM characteristics. If an administrator does not want to 
reveal this information, then these tables should be considered 
sensitive/vulnerable. 


SNMP versions prior to SNMPv3 did not include adequate security. 
Even if the network itself is secure (for example by using IPsec), 
there is no control as to who on the secure network is allowed to 
access and GET/SET (read/change/create/delete) the objects in this 
MIB module. 


Implementations SHOULD provide the security features described by the 
SNMPv3 framework (see [RFC3410]), and implementations claiming 
compliance to the SNMPv3 standard MUST include full support for 
authentication and privacy via the User-based Security Model (USM) 
[RFC3414] with the AES cipher algorithm [RFC3826]. Implementations 
MAY also provide support for the Transport Security Model (TSM) 
[RFC5591] in combination with a secure transport such as SSH 
[RFC5592] or TLS/DTLS [RFC6353]. 


Further, deployment of SNMP versions prior to SNMPv3 is NOT 
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 
enable cryptographic security. It is then a customer/operator 
responsibility to ensure that the SNMP entity giving access to an 
instance of this MIB module is properly configured to give access to 
the objects only to those principals (users) that have legitimate 
rights to indeed GET or SET (change/create/delete) them. 
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10. 


IANA Considerations 


As described in [RFC4221] and [RFC6639], and as requested in the 
MPLS-TC-STD-MIB [RFC3811], MPLS-related Standards Track MIB modules 
should be rooted under the mplsStdMIB subtree. The following 
subsection lists a new assignment that has been made by IANA under 
the mplsStdMIB subtree for the MPLS-OAM-ID-STD-MIB module defined in 
this document. New assignments can only be made via a Standards 
Action as specified in [RFC5226]. 


Te IANA Considerations for MPLS-OAM-ID-STD-MIB 


IANA has to assign the OID { mplsStdMIB 21 } to the 
MPLS-OAM-ID-STD-MIB module specified in this document. 
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